Synchronizing agent for multiple clients/applications on a computer system

ABSTRACT

A suite of features for use by a synchronization agent to synchronize data records among two or more clients. Some of the embodiments enhance conventional synchronization features by providing customizable response of a synchronization agent to an operator&#39;s needs. For example, conditions may be defined that permit various client records to be synchronized according to policies that differ from default synchronization policies. Different synchronization policies may be triggered by the content of data records or by the clients from which the records originate. Other features may cause automatic population of fields within data records or resolution of synchronization conflicts.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of priority afforded by provisionalapplication Ser. No. 60/588,394 filed Jul. 16, 2004.

BACKGROUND

The present invention relates to data synchronization agents for use incomputer systems.

Modern computer users often find that they are required to store copiesof redundant data on multiple clients. For example, an operator maymaintain personal scheduling information, contacts and lists of actionitems on both a desktop computer and a portable personal digitalassistant. Moreover, operators may maintain such data on personalinformation managers (e.g., Microsoft's Outlook, Lotus Notes, amongothers) and also centralized enterprise resource planning applicationssuch as SAP's R/3 application. To relieve operators from having to entercommon data records multiple times for multiple applications (herein,“clients”), synchronization agents can be used.

Herein, a “synchronization agent” refers to a body of applications thatsynchronize data records among multiple clients. PalmSource, Inc.'sHotSync application and PumaTech Corporation's Intellisync suite ofapplications are examples of such synchronization agents. Knownsynchronization agents adequately synchronize data records among a pairof clients but they are unwieldy in many aspects. Known synchronizationagents tend to provide a single synchronization solution for all usersor to permit operators to specify different synchronization rules on avery coarse scale (e.g., calendar items synchronized in one fashion andcontacts items specified in another fashion). They do not, however,permit operators to customize operation of the synchronization agentalong parameters that are critical to the operators' use of the datarecords. For example, known synchronization agents do not permitoperators to:

-   -   specify different synchronization rules based on client codes,        contact names or company names;    -   restrict synchronization operations to single records, to        records that meet a predetermined date restriction, or to tasks        records that are open; and    -   resolve synchronization conflicts on a field-by-field basis and        on a sweeping basis at the same time.        Accordingly, the present inventors perceive these and other        needs in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a synchronization application ina computer system, according to an embodiment of the present invention.

FIG. 2 illustrates a method according to an embodiment of the presentinvention.

FIG. 3 illustrates a method according to another embodiment of thepresent invention.

FIG. 4 is a screen shot illustrating an exemplary dialog box thatpermits conflict resolution according to an embodiment of the presentinvention.

FIG. 5 illustrates another method according to an embodiment of thepresent invention.

FIG. 6 illustrates a method according to another embodiment of thepresent invention.

FIG. 7 illustrates a method according to a further embodiment of thepresent invention.

FIG. 8 illustrates a method according to another embodiment of thepresent invention.

FIG. 9 illustrates an exemplary preview pane according to an embodimentof the present invention.

FIG. 10 illustrates a method according to a further embodiment of thepresent invention.

FIG. 11 illustrates another method according to a n embodiment of thepresent invention.

FIG. 12 is a method according to an embodiment of the present invention.

FIGS. 13( a) and 13(b) illustrate examples of linking data for use withembodiments of the present invention.

FIG. 14 illustrates an exemplary system according to an embodiment ofthe present invention.

DETAILED DESCRIPTION

As described herein, the inventors propose a suite of synchronizationfeatures for use by a synchronization agent. Some of the embodimentsenhance conventional synchronization features by providing customizableresponse of a synchronization agent to an operator's needs. For example,different synchronization operations may be defined based upon thecontent of data records themselves, by records' time of creation orediting or by records' status.

FIG. 1 is a simplified block diagram of a synchronization application ina computer system 100. The system 100 may include a pair of clients 110,120. Each client includes one or more applications 112, 122 and variousdata sets 114, 124. The system 100 of FIG. 1 applies to systems in whichthe clients 110, 120 are different, discrete hardware systems (e.g.,terminal and server, PDA and terminal) and also to systems in which theclients 110, 120 are different applications operating on a commonhardware platform (e.g., Microsoft's Outlook and SAP's R/3applications). Unless otherwise indicated herein, the principles of thepresent invention apply equally as well to both embodiments.

The system 100 also includes a synchronization agent 130, an applicationthat manages synchronization of data records between the clients 110,120. Typically, each client 110, 120 includes an appropriate interface116, 126 through which the client recognizes synchronization operationsfrom the synchronization agent 130. When activated, the synchronizationagent 130 reviews records from various data sets 114, 124 of the clientsto determine whether the data records on each client should be copied tothe other client to keep them current. In this regard, the architectureand operation of synchronization systems 100 is well known.

According to an embodiment of the present invention, a synchronizationagent 130 applies different synchronization rules to different recordsstored in the datasets 114, 124 of the clients 110, 120. In such anembodiment, synchronization options are determined from fields of thedata records themselves. For example, different synchronization optionsmay be applied based on a company name, a billing code, a project codeor a categories field provided within such records. Synchronizationoptions would be defined in a synchronization rule set 132 defined forthe synchronization agent 130.

FIG. 2 illustrates a method of operation 200 according to one suchembodiment. The method considers data records of each clientiteratively. For each client, the method 200 identifies data recordsthat are to be synchronized (box 210). Each record is compared against arule profile that defines rules to be applied to the data records anddetermines whether a match occurs (box 220). If so, synchronizationoccurs as defined in the matching rule (box 230). Otherwise,synchronization occurs according to a default rule (box 240). The methodmay be repeated for as many data records on the clients as are to besynchronized.

TABLE 1 RULE CONDITION SYNCHRONIZATION POLICY 1 Company Name = Client110 records overwrite client 120 “XYZ Corp.” records; Flag conflicts forresolution. 2 Company Name = Client 120 records overwrite client 110“ABC Inc.” records, regardless of conflicts. 3 Category = Client 110records cannot be overwritten. “Firm” Conflicts with client 120 recordscause duplicates to be created at client 110. 4 Category = Do notsynchronize records. “Personal” Default Synchronize; flag conflicts forresolution.

Table 1 illustrates an exemplary synchronization rule set with fourrules. In this embodiment, two rules are conditioned on company name.The third and fourth rules are based on a field called “category.”Different synchronization policies are defined therein. Any data recordsthat matches the condition(s) specified in a rule will be synchronizedas defined in the corresponding synchronization policy. Data recordsthat miss conditions of all rules may be synchronized according to adefault rule. In an embodiment, data records that match conditions ofmultiple rules may be flagged to a system operator for resolution.Alternatively, the rules may include a priority indicator that specifieswhich rules take precedence over other rules.

As noted, various fields in client datasets 114, 124 may support ruleconditions. Typically, conditions will be based on client names, clientcodes, project codes, matter numbers, account owners and statusindicators such as open/closed indicators. Such examples are not meantto be limiting. Indeed, any field supported by the Microsoft Outlookfield template may be included as a condition in a rule set.

Table 1, of course, provides a simple example of a rule set. The presentinvention includes more complicated definitions of conditions andaccommodates, for example, common Boolean operators (AND, OR, NOT) tobuild conditions from combinations of multiple fields.

Another embodiment provides a technique for managing conflicts amongdata records stored by multiple clients 110, 120. According to anembodiment, when a synchronization conflict occurs, data representingconflicting data records are displayed and an operator is permitted toidentify which fields from the data records are to be retained forsynchronization.

FIG. 3 illustrates a method 300 according to an embodiment of thepresent invention. According to the method, when synchronization occursand a conflict is identified between data records on multiple clients,the method 300 displays field contents of the conflicting records (box310). The method 300 queries an operator to select fields that containproper data values for synchronization (box 320) and, in response to theoperator's selection, generates a new record that is used forsynchronization (box 330).

FIG. 4 is a screen shot illustrating an exemplary dialog box thatpresents conflicting records for resolution. Table 2 illustratesexemplary data that might be presented by a pair of conflicting datarecords. In the foregoing embodiment, the dialog box might present dataas illustrated in the columns labeled “client 1” and client 2” of Table2. An operator may identify fields that possess correct data as shown inthe “selection” column. The operator's selections may generate a finalrecord that is unique compared to the data records stored by eachclient. This final record can be used as a basis for furthersynchronization. For example, the final record may be stored at bothclients.

TABLE 2 OPERATOR'S CLIENT 1 CLIENT 2 SELECTION FINAL RECORD Full NameJoe Smith Joseph E. Smith Client 2 Joseph E. Smith Company ABC Corp. ABCCorp. No Conflict ABC Corp. Job Title VP, Engineering VP Client 1 VP,Engineering Address 1500 Main Street 1500 Main Street, Client 2 1500Main Street, Suite 500 Suite 500 City Springfield Springfield NoConflict Springfield ZIP/Postal Code 12345 12345 No Conflict 12345

Another embodiment of the present invention provides a “synchronizethis” feature for a client application. In the embodiment, as anoperator browses through data records of a client application, theoperator may generate a command to synchronize a single data recordcurrently being viewed. This embodiment prevents the synchronizing agentfrom having to survey all data records in a dataset to determine whichrecords need to be synchronized. Accordingly, the speed of thesynchronization operation is improved.

FIG. 5 is a flow diagram of another method 500 according to anembodiment of the present invention. According to the method, when anoperator enters a “synchronize this” command (box 510), the method 500identifies a data record that currently is being viewed through theclient application (box 520). The method 500 synchronizes the currentrecord and no others (box 530). Thereafter, the method terminates.

In an embodiment, the synchronize this command may be entered via anicon embedded in the client application. Many applications, such asMicrosoft Outlook for example, provide software tools to permit othersoftware vendors to embed icons in the graphical user interfaces oftheir applications. Thus, the command may be entered via a toolbar oricon set that is integrated into the client application itself (e.g.,Microsoft Outlook, SAP R/3) or, alternatively, it may be entered throughthe client's operation system. In either case, the command causes anapplication to determine which record is being viewed currently andsynchronizes the record itself.

FIG. 6 illustrates another synchronization method 600 according to anembodiment of the present invention. This embodiment permits operatorsto specify unique synchronization rule sets for each client undergoingsynchronization. According to an embodiment, synchronization begins byidentifying records that are to be synchronized (box 610). Thereafter,for each record, the method 600 determines whether the respective recordshould be synchronized on the first client (box 620). If so, the recordis stored to the first client (box 630). The method 600 also determineswhether the record should be synchronized on the second client (box 640)and, if so, it stores the record to the second client (box 650). Theoperations of boxes 640 and 650 may be repeated for as many clients aresubject to synchronization.

Operation of the foregoing method may be facilitated by asynchronization agent 660 that stores rule sets 670, 680 for each of theclients subject to synchronization. The rule sets 670, 680 may specify,for example, that records are to be copied to the client, may not becopied to the client or shall be copied to the client only if definedconditions are met.

FIG. 7 illustrates a synchronization method 700 according to a furtherembodiment of the present invention. In this embodiment, the method 700identifies incomplete data records and, with reference to other datarecords previously stored by the clients, proposes data to supplementdata of the incomplete data record. The method 700 may begin byidentifying records that are to be synchronized (box 710). For eachrecord, the method determines whether the record is incomplete (box720). If so, the method 700 may survey data sets of the various clientsto compare completed fields of the record being synchronized againstother data records stored by the clients (box 730). Based on a match,the method 700 may prompt the operator to complete of the record beingsynchronized, providing data culled from one or more other records (box740). An operator may respond by accepting the proposed data, byoverwriting the proposal (box 760) or by indicating that the recordshall be stored in its incomplete form. The method 700 synchronizes thedata records as indicated by the operator (box 770).

Of course, the operations of boxes 730-760 need not be performed for adata record that is identified as complete. Instead, synchronization maybe performed directly upon a complete data record (box 780).

FIG. 8 illustrates another method 800 according to embodiment of thepresent invention. According to this embodiment, after candidate recordsare identified but before synchronization occurs, the method 800identifies the candidate records to an operator and permits the operatorto select or de-select records from the remainder of the synchronizationoperation. According to the method 800, when a synchronization operationbegins, the method identifies client records to be synchronized (box810). Record identification may occur by any conventional process.Thereafter and before new data is written to client data sets, themethod 800 generates a display that identifies records to besynchronized (box 820). The method 800 queries an operator to select ordeselect records for synchronization (box 830). Thereafter, conventionalsynchronization is performed but it is limited to the records selectedby an operator (box 840).

FIG. 9 illustrates an exemplary preview pane 900 that is consistent withthe embodiment of FIG. 8. The FIG. 9 includes a record array 910, whichidentifies contents of several records that are identified as candidatesfor synchronization. The preview pane 900 also includes check boxes 920,one corresponding to each record 910 to permit an operator to select orde-select individual records. The preview pane 900 also may include anumber of ancillary navigation buttons, for example “synchronize all”930, “synchronize none” 940, “continue” 950 and “cancel” 960, to permitother navigation and selection options. Of course, the present inventionfinds application with displays having different layouts than are shownin FIG. 9.

In an embodiment, the preview pane of FIG. 9 may display records ofdifferent types at different stages of the display. That is, a firstpreview pane may display calendar records for synchronization first andpermit an operator to review, select/de-select and synchronize thoserecords. Thereafter, a new preview pane may present tasks items.Following synchronization of the tasks items, another preview pane maypresent contacts items. This staggered preview mode is illustratedschematically by the bounding boxes of FIG. 8.

FIG. 10 illustrates a method 1000 according to another embodiment of thepresent invention. This embodiment permits an operator to limit asynchronization operation to data records that match a data rangeidentifier entered by the operator. In the embodiment, the method 1000begins upon receipt of a synchronization command that includes a daterange identifier (box 1010). The method 1000 identifies records fromeach client data set that are candidates for synchronization (box 1020).This initial identification process may occur according to conventionalprocesses. Prior to synchronizing individual data records, the methodmay compare a time stamp of the record to a data range identified aspart of the synchronization command (box 1030). If the time stamp fallswithin the specified date range, the record is synchronized, again,according to conventional processes (boxes 1040, 1050). If not,synchronization is not performed and the method may advance to the nextrecord.

FIG. 11 illustrates another method 1100 according to an embodiment ofthe present invention. In certain scenarios, a synchronization agent maysupport synchronization between a central client (say, a server) and anumber of other ‘local’ clients such as notebook PCs deployed among afirm's sales force. In the embodiment, each ‘local’ client maysynchronize its data records to the central client according to rulesthat are defined uniquely for the local client. In other words,different local clients may define different synchronization operationswith the same central client.

According to the embodiment, when a synchronization command is entered,the method 1100 may authenticate the local client (box 1110) todetermine which client is engaged with the central client. Thereafter,the method 1100 may retrieve a synchronization rule set that is specificto the local client (box 1120). The method 1100 continues bysynchronizing data records (e.g., calendar items, tasks and contacts) asdetermined by the synchronization rules (boxes 1130-1150). For each datarecords, the method 1100 determines whether synchronization of therecord would cause write-protected records at the central client to beover-written (box 1160). If so, the record is not synchronized (box1170). This scheme prevents protected data records at the centralclient, which perhaps could be amended at one or more local clientsites, from becoming corrupted.

In another embodiment, the present invention may use links establishedamong records of a first client to automatically populate data ofcorresponding records at a second client. This embodiment findsapplication, for example, in SAP's Customer Relationship Management(“CRM”) applications and elsewhere, where all records are required to beassociated with a business partner. That is, records include a businesspartner field that is a “critical field,” it must be completed for therecord to be admitted to the application. In some installations,however, new records may be admitted to other clients (e.g., a personalinformation manager) that either do not support the critical field or donot require that the critical field be completed before the record isadmitted to the other client. Synchronization between the two clients,the CRM application and the personal information manager, may cause aconflict in data management policies.

According to an embodiment, a synchronization agent may resolve aconflict by examining links established between records of a client andpopulating missing critical field data in a new record by usingcorresponding data from a previously admitted record. FIG. 12 is amethod according to the embodiment. The method may begin by identifyingall records on a first client that are candidates for synchronization(box 1210). The method determines whether critical field data in acandidate record is incomplete (box 1220). If so, the method 1200further determines whether the candidate record is linked expressly toother records stored by the same client (box 1230). If so, the methodmay identify critical field data from the linked record for use with thecandidate record (box 1240). The critical field data may be stored inthe record on the same client from which the candidate record originated(e.g., the personal information manager in the example above) or from arecord on the second client (e.g., the CRM application) corresponding tothe linked record. Having identified the critical field data from thelinked record, it may be copied to the new record or otherwise used foradmitting a new record to the second client (box 1250). Thereafter, thesynchronization operation may progress to completion (box 1260). Ofcourse, if no linked records are found, the method 1200 may query anoperator for the missing data (box 1270).

FIGS. 13( a) and 13(b) illustrate examples of linking data supported bythe Microsoft Outlook application. FIG. 13( a) is a screen short of acontacts record and FIG. 13( b) is a screen shot of a task record. Bothrecords include a “contacts” field that, when activated, permit anoperator to indicate that the record is associated with another recordstored by the application. For example, an operator could identify alink between contacts records for Werner Wolf and David Sacks. Havingdetermined during a synchronization operation that critical field datais not provided for the Werner Wolf record, a synchronization agent mayfollow the link to the David Sacks record and, if critical field data isavailable, the synchronization agent may copy the data for use during asynchronization operation in which the Werner Wolf record is copied toanother client application. Other applications may support links amongrecords in other ways.

In additional to population of critical field data of records, asynchronization agent may populate other record fields by traversingthese links as well. Accordingly, if the synchronization agentdetermined that an address field or a company name field wereincomplete, the synchronization agent could copy such information from alinked record. Of course, in all of the foregoing embodiments, thesynchronization agent may query an operator to confirm copied data priorto completing the synchronization operation.

Another embodiment of the present invention provides support for CRMapplications by supporting synchronization of customer “snapshots” froma CRM application to a second client. FIG. 14 illustrates one suchembodiment. There a system 1400 includes a CRM client 1410, a secondclient 1420 and a synchronization agent 1430. Although not so limited,it may be convenient to think of the second client 1420 as a notebookcomputer, a tablet computer or some other mobile client that hasintermittent access to the CRM client 1210.

The CRM client 1410 may include an application component 1412 and adatabase 1414 that stores customer related data. In addition to recordsrepresenting activities, contacts, appointments and tasks as describedabove, conventional CRM applications store records representing customersales, quotations, customer accounts and the like.

The synchronization agent 1430 may store a data set representing reporttemplates that may be used for synchronization. Each templatecorresponds to a predetermined “snapshot,” a summary report identifyingstatus along a selected CRM dimension. Operators may selectively enablevarious templates for each client and may enable different sets oftemplates for different customers. During synchronization, asynchronization agent may engage the CRM client to collect summary dataas dictated by the selected template and create snapshot files on thesecond client. For example, each template may be represented on aseparate sheet of a spreadsheet file on the second client, each filerepresenting a snapshot of an individual customer. Through use of thesnapshot feature, an operator may generate summary data records from aCRM application that are amenable to mobile applications, among others.

Functionality of the foregoing embodiments may be provided on variouscomputer platforms executing program instructions. Commonly, suchcomputing platforms include one or more processors, a memory system andvarious input/output (I/O) devices. The processor may be any of aplurality of conventional processing systems, including microprocessors,digital signal processors and field programmable logic arrays. In someapplications, it may be advantageous to provide multiple processors (notshown) in the platform. The processor(s) execute program instructionsstored in the memory system. The memory system may include anycombination of conventional memory circuits, including electrical,magnetic or optical memory systems. For example, the memory system mayinclude read only memories, random access memories and bulk storage. Thememory system not only stores the program instructions representing thevarious methods described herein but also can store the data items onwhich these methods operate. The I/O devices permit communication withexternal devices (not shown) and operators.

Several embodiments of the present invention are specificallyillustrated and described herein. However, it will be appreciated thatmodifications and variations of the present invention are covered by theabove teachings and within the purview of the appended claims withoutdeparting from the spirit and intended scope of the invention.

1. A method for synchronizing data records among multiple clients,comprising: identifying data records from the clients that arecandidates for synchronization, comparing content of a candidate recordagainst a synchronization rule set, the synchronization rule set beingspecific to each of the multiple clients, and each rule set including acondition to which the content of the candidate record is compared and aresponse associated with the condition, wherein the comparing includesevaluating conditions built using Boolean operators and combinations ofmultiple fields of content in the data record, and if the comparisonbetween the condition and the data record content generates a match,synchronizing the candidate record according to the synchronization ruleset but the candidate record is not synchronized if the comparison doesnot generate a match, wherein when a conflict exists among copies of thecandidate record stored by the multiple clients, the synchronizingcomprises: displaying contents of the conflicting record copies on afield-by-field basis, based on operator input, selecting fields fromamong the displayed conflicting copies that are displayed as a finalsynchronization data record with the displayed contents of theconflicting record copies, generating a synchronization record fromfield data of the conflicting copies displayed as a finalsynchronization data record, and storing the synchronization record toat least one client.
 2. The method of claim 1, wherein thesynchronization rule set includes a client record as a condition.
 3. Themethod of claim 1, wherein the synchronization rule set includesdifferent rules for different clients.
 4. A method for synchronizingdata records among multiple clients, comprising: determining whether aconflict exists among data records stored by multiple clients bycomparing content of the common data records against a synchronizationrule set, the synchronization rule set specific to each of the multipleclients, and each rule set including a condition to which the content ofthe common data record is compared and a response associated with thecondition, the conflict arising because copies of a common data recordstored on separate clients were revised independently of each otherprior to synchronization, wherein the comparing includes evaluatingconditions built using Boolean operators and combinations of multiplefields of content in the data record; displaying contents of theconflicting record copies on a field-by-field basis, based on operatorinput, selecting fields from among the displayed copies that aredisplayed as a final synchronization data record with the displayedcontents of the record copies, generating a synchronization record fromthe conflicting record copies displayed as the final synchronizationdata record, and storing the final synchronization data record to atleast one client.
 5. The method of claim 4, wherein a conflict isdetermined when copies of data records on different clients havedifferent data.
 6. The method for synchronizing data records amongmultiple clients of claim 4, comprising: responsive to the operatorinput, identifying a data record currently being viewed by a firstclient, and synchronizing the currently viewed data record with acorresponding data record stored by a second client.
 7. The method ofclaim 6, wherein no other records of the first client are synchronizedin response to the operator command.
 8. The method of claim 1, whereinthe synchronization further comprises: if a candidate record isincomplete, identifying a second record related to the candidate record,completing data of the candidate record using data from the secondrecord, and synchronizing at least one client using the completedcandidate the record.
 9. The method of claim 8, wherein the secondrecord is identified from an express link stored by the first record.10. The method of claim 8, wherein the identifying comprises: comparingdata of the candidate record to corresponding data from other storedrecords, and selecting the second record based on a degree of similaritybetween the data of the candidate record and the second record.
 11. Themethod of claim 8, further comprising, prior to the synchronizing,querying an operator for confirmation of the completed data.
 12. Themethod of claim 8, wherein the second record is stored on a clientdifferent from the first record.
 13. The method of claim 4, furthercomprising: identifying task records from the clients that arecandidates for synchronization, determining whether any of the candidatetask records show that the task has been completed, synchronizing taskrecords that have not been completed.
 14. A method for synchronizingdata records among multiple clients, comprising: identifying datarecords from the clients that are candidates for synchronization,displaying with each of the identified data records a query to anoperator to select/de-select each of the identified data records forinclusion in a synchronization operation, and responsive to theoperator's selections, synchronizing selected records, wherein when aconflict exists among copies of the candidate record stored by themultiple clients, the synchronizing comprises: displaying contents ofthe conflicting copies on a field-by-field basis, based on operatorinput, selecting fields from among the displayed conflicting copies thatare displayed as a final synchronization data record with the displayedcontents of the record copies, generating a synchronization record fromfield data of the conflicting copies displayed as the finalsynchronization data record, and storing the synchronization record toat least one client.
 15. The method of claim 14, wherein de-selectedrecords are excluded from synchronization.
 16. The method of claim 6,wherein the data record currently being viewed by the first client is acurrently-active data record at the first client.
 17. The method ofclaim 4, wherein the final synchronization data record is unique incomparison to the conflicting records.